I'm guessing you will be the one working on these issues? Any way to help you get those fixed faster? And curoius about GART? What is that and what makes the transfer so much higher? Is the tranfer rate now on the x1000 at about 450MIB/s? Is this a bottleneck as in now?
And too bad we don't have the money to give amd so we could get those documents. That would probably mean in millions of euro. Wish i could win the lottery.
Quote:
There are three things that would help with CPU based video decoding: - Textured video (overlay is obsolete) - GART for fast data transfer to/from VRAM (boosts the transfer rate from ~450 MiB/s to a theoretical 4 GiB/s on the A1-X1000, which is great for HD video) - Multi-core support (helps a lot with H.264 1080p decoding)
All of these are on the to-do lists. We'll get there eventually. Once these are in place, the PA6T will probably have the power to do H.264 1080p video decoding.
I'm guessing you will be the one working on these issues?
It will take more than just me. Taking advantage of GART will require improvements to Picasso96, and video players such as DvPlayer and mplayer will need to be updated for textured video. I've already had discussions with other developers about these things.
Quote:
Any way to help you get those fixed faster?
Hmmm. I personally have limited time as I'm working on building my company. Since success there is critical for me, that is top priority. So, simply donating won't magically give me more time to work on it.
However, this isn't a one man show (see above). Right now I think that your best bet is to encourage those "sitting on the fence" to go out and get PCI-Express capable machines and/or Radeon HD cards (plus the latest drivers). That will provide more funds for development, which will help move things along. Plus, the more users we have the better. Of course, this will be a lot easier once the Warp3D drivers for Radeon HD 5xxx-6xxx cards are out.
Oh yeah, supporting DvPlayer is also worthwhile.
Quote:
And curoius about GART? What is that and what makes the transfer so much higher?
Graphics Address Remapping Table (GART) is a technique where main memory is mapped into the graphics card's internal address space next to VRAM. This allows the GPU to directly access data in main memory using DMA.
Quote:
Is the tranfer rate now on the x1000 at about 450MIB/s? Is this a bottleneck as in now?
Yes, that is roughly the current limit. This is because the only way to achieve fast and efficient transfers across PCI/PCIe is to transfer large blocks of data at a time.** Using DMA is the only way to make this happen. DMA also has the advantage that the CPU isn't involved and can, therefore, be working on something else.
Quote:
And too bad we don't have the money to give amd so we could get those documents. That would probably mean in millions of euro. Wish i could win the lottery.
With that much money we could probably develop our own graphics card.
Hans
** PCIe has a particularly large penalty for transferring small blocks (e.g., 32-bits) at a time. On the A1-X1000, altivec is used to transfer 128-bits (16 bytes) at a time, but that's still not big enough for top speeds.
Antique wrote: Any way to help you get those fixed faster?
Actually, what would help is if someone provided sample YUV images and a small test program that displays them using the existing overlay functionality. I need test images in the following format: - RGBFB_YUV422CGX - RGBFB_YUV420P - RGBFB_YUV410P
Basically, the test program would open a Picasso96 overlay window in each of these formats, and display a test image. The source-code would also have to be provided, so that I could adapt it for testing the textured video functionality.
LiveForIt wrote: I can do RGBFB_YUV422 PIP, I have something like that somewhere I think, I was experimenting whit Mplayer some years ago.
That would be helpful, thanks. If you have that, then it shouldn't be hard to add the other pixel formats too. You just need image data in the two planar formats. Ffmpeg could be used to dump a frame or two to disk in those formats (link). The test program could then, load in the dumped file and display it using overlay.
Generally speaking, to get an NDA with a company for technical documentation requires convincing them that giving us the docs will make them a lot of money. This is because we'd be taking up their engineers' time with questions about any confusing and missing parts of the documentation. We're not really in the position to make them a lot of money.
I've had far more success than rejections. Successes include ATI (before AMD), AMD, Uli, PA Semi, Via, PLX Tech, Jmicron, Freescale, and others. Rejections include Nvidia, Intel, Ricoh. Nether list is all-inclusive, but what I can remember off the top of my head has more than doule the successes than failures.
My guidelines to getting an NDA with such people, for a hobbyist sort of project like I've ben involved in myself: 1) Try. you certainly don't get what you don't ask for. Heck, Via's response to my NDA request was a PDF file in a reply email, nothing else. 2) Have a legitimate company in a relevant industry. Your company sounds like image processing, which is related to video processing, which is very relevant to this thread's stated topic. 3) Have a professional website for said company of yours. Most vendors do check up on you before calling or emailing. 4) It's OK to be a startup company. (I talk about our company here being an embedded system design house, which we do aspire to be, and have a variety of non-Amiga projects like that) 5) Do NOT say the A-word. No one takes Amiga seriously anymore out there. Sorry. Instead, talk Linux, QNX, or some other embedded OS that may need driver improvement in, and would reasonably be part of or host to your intended product, with the intent of sharing code with what we in this discussion want to happen. (same for design modularity/reuse in a hardware project) 6) Be honest. Try not to talk about Amiga. If you find yourself getting herded into saying that, don't lie your way out of it. Code sharing with an oddball platform that interests you isn't a bad thing. Exaggerate a little, but liing will get you in trouble at some point. 7) Be closed-source/proprietary. you won't get NDA protected documentation for an open-source project. Closed-source is the way to go.
I believe Hans fits my own guidelines pretty well, and I'd encourage him to have a go at requesting NDA to these things. I'd encourage trying via the AMD Embedded Developer Support site. it's relatively easy to get into that, and it has a path to the Embedded Discrete Graphics products group NDA. That wasn't hard either. Once there, you may have contact with the right people to ask about the video acceleration NDA, or someone who can help get you to the right people.
Doesn't hurt to ask. Maybe they'll say no, but at least give them the opportunity to say yes.
Doesn't hurt to ask. Maybe they'll say no, but at least give them the opportunity to say yes.
I already did try. At first the "developer relations" guy fobbed me off with the generic "wait for the open documentation" reply. When I reiterated that his own boss had said that the UVD docs wouldn't be opened up ... the line went dead.
NOTE: I didn't mention Amiga by name, and was very clear about what documentation I was requesting access to and that it was for a closed-source driver.
To be honest, someone else needs to pick up the ball on this. I don't have the time to add HW video decoding to my workload.
@Hans >Actually, what would help is if someone provided sample YUV images and a small test program [...] in the following format:- RGBFB_YUV*
Do you think that Warp3D may be used to decode YUV with the multi-texturing feature ?
@all Can someone describe (Input format (yuv nnn?) -> Output format (rgba?) precisely what kind of "overlay_like conversion" need all those video players ???? So perhaps I can have a look too..
** PCIe has a particularly large penalty for transferring small blocks (e.g., 32-bits) at a time. On the A1-X1000, altivec is used to transfer 128-bits (16 bytes) at a time, but that's still not big enough for top speeds.
So the X1000 currently does all gfx operations by PIO??! Even rectfill and moving windows and screens, draw shadows etc. and obviously BltBitMap for painting the video on a window?
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
thellier wrote: @Hans >Actually, what would help is if someone provided sample YUV images and a small test program [...] in the following format:- RGBFB_YUV*
Do you think that Warp3D may be used to decode YUV with the multi-texturing feature ?
Could Warp3D's multitexturing handle the equations that Karlos posted if the Y, U, and V channels were in separate textures? If so, then you might be able to display the planar modes YUV420P and YUV410P. The interleaved format YUV422 won't be possible, because the U and V data is shared between pixels. This requires explicit driver (and HW) support.
** PCIe has a particularly large penalty for transferring small blocks (e.g., 32-bits) at a time. On the A1-X1000, altivec is used to transfer 128-bits (16 bytes) at a time, but that's still not big enough for top speeds.
So the X1000 currently does all gfx operations by PIO??! Even rectfill and moving windows and screens, draw shadows etc. and obviously BltBitMap for painting the video on a window?
I'm not sure what you're asking. All of the functions that you're talking about are HW accelerated, so the RAM to VRAM transfer speed is almost irrelevant.
>Could Warp3D's multitexturing handle the equations that Karlos posted if the Y, U, and V channels were in separate textures?
Yes,I think it may be possible to use Warp3D's multitexturing for converting YUV to RGB W3D_MODULATE is a multiply operation so can multiply a coef (stored in vertices colors) with a (quad)texture Y is the first texture * ycoefs U is the second smaller texture * ucoefs V is the third smaller texture * vcoefs
If someone can post an YUV image (with the same format as the amiga-video-player that miss overlay) then I can give a try...
>The interleaved format YUV422 won't be possible, because the U and V data is shared between pixels Perhaps no: if we consider that U (or V) is a separate texture with a smaller size
Note that most Radeons actually support one or the other form of YUV textures, but support for that was never included in Warp3D. It's difficult to retrofit it into the compositing code since that would only work under certain contraints. The R200 for example can use separate YUV plane data but only when using the full three texture units. That means there is no room for a separate alpha map, so things would need to be done in multiple passes with temporary bitmaps.
Here's hoping we can support more of that stuff on the later chips, with Gallium there is certainly better chances to see this working.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Rogue wrote: Note that most Radeons actually support one or the other form of YUV textures, but support for that was never included in Warp3D. It's difficult to retrofit it into the compositing code since that would only work under certain contraints. The R200 for example can use separate YUV plane data but only when using the full three texture units. That means there is no room for a separate alpha map, so things would need to be done in multiple passes with temporary bitmaps.
Interestingly, the R200 entry on wikipedia claims that it can handle up to 6 textures per pass via some "loop-back" technique. I have no idea what the restrictions are, but it could still be doable. If not, then it should still be able to handle YUV422, as that requires just one texture. Plus, they have overlay.
Quote:
Here's hoping we can support more of that stuff on the later chips, with Gallium there is certainly better chances to see this working.
Radeon HD cards have 4 or more texture units (depending on the series), which is enough for separate Y, U, and V textures plus an alpha mask. That will cover planar YUV modes. I already have example shader code for this, although it will have to be adapted.
Radeon X1000 (R500) series cards also have 4 or more texture units, but I'll probably stick to the Radeon HD series only (almost no one uses the Radeon X1000 series, and there are so many other things to spend time on).
It's interesting, so what you rally wont is not to convert the YUV422 into RGB, but keep components divided and use shadier to mix it all.
I don't know have you thinking about doing it, B/W contrast or Y component, will need to shade the color more black or more white, will you need two textures whit alpha? Black texture and a white texture and just manipulate the alpha?
If I remember correct the Y component plain is larger than UV component plains, so it will need to scale to fit etch other, so it's not loss less format.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
